nice workaround!

Thanks! 😄 Took a while to find — the older api-extractor just hard-errored on export * as ns, the newer one resolves it once the workspace packages are bundled.

why wouldn't we want to enable this?

Good question. I disabled it mainly because of how it interacts with bundledPackages: with the namespace bundling, each plugin report would inline all of @livekit/agents's API into its .api.md, so every plugin report becomes huge and churns on every core change. Combined with the repo gitignoring *.md (only 2 reports were ever force-added) and api:check not being in CI, it felt like the report wasn't really being used.

That said, I think it's genuinely valuable for the core @livekit/agents package — it doesn't bundle anything, so its report stays clean and gives a real public-API diff. Happy to enable it just for core (commit agents/etc/agents.api.md + a !etc/*.api.md gitignore exception) and keep plugins structural-only. Want me to do that?

ok, I think it makes sense to stay disabled for now. I had opened a PR to fix the underlying issue of api-extractor with the namespace export here microsoft/rushstack#5810

Once that gets merged we can revert the bundledPackages workaround and re-enable here as well.

this seems a bit excessive with all the logs underneath also be setting to none.

What's your thinking behind it?

Fair — it is heavy-handed. Two parts:

1. The explicit per-message list isn't redundant with default: api-extractor ships built-in per-message defaults (ae-forgotten-export, ae-missing-release-tag, etc. default to warning) that take precedence over the user's default entry, so default: none alone doesn't silence them — I had to set each one explicitly (verified empirically).
2. You're right that it silences more than ideal. The release-tag family + unresolved-link/inheritdoc are conventions this repo deliberately doesn't use, so those are safe to drop. The one I'd rather keep is ae-forgotten-export (catches types used in the public API but not exported) — but the core currently has ~4 (OutputSchema, AgentConstructor, PromptTemplate, UpdatePromptArgs), so keeping it as a warning means exporting those, which is a small public-API change.

Happy to trim to just the release-tag + link families and fix those 4 forgotten exports if you'd prefer the gate to stay meaningful — let me know.

yeah, forgotten export sounds useful to keep

🟡 api:update task dependency not updated consistently with api:check

The PR changed api:check's dependsOn from ["^build"] to ["build"] to ensure the current package is built before API Extractor runs (it needs ./dist/index.d.ts). However, api:update at turbo.json:127 was left with the old ["^build"], which only builds upstream workspace dependencies — not the current package itself. Since api:update also runs api-extractor run and requires the current package's ./dist/index.d.ts, running turbo run api:update on a clean workspace will fail because the entry point file doesn't exist. The fix applied to api:check should also be applied to api:update for consistency.

In turbo.json, the api:check task was correctly updated from dependsOn: ["^build"] to dependsOn: ["build"] so that the current package is built before API Extractor runs (it needs ./dist/index.d.ts). The same change should be applied to the api:update task at line 127, which also runs api-extractor run and has the same dependency on the current package's build output. Change api:update's dependsOn from ["^build"] to ["build"].

Was this helpful? React with 👍 or 👎 to provide feedback.

@toubatbrian this seems valid

🔴 Tool-started signal never fires when all tool calls in a batch are duplicate-rejected, potentially hanging downstream waiters

The "first tool started" signal is never resolved (onUserToolStarted at agents/src/voice/generation.ts:1189) when the executor's duplicate check returns early (agents/src/voice/tool_executor.ts:220), so any downstream code awaiting that signal hangs indefinitely.

Impact: If an LLM emits a tool call that is duplicate-rejected (e.g. onDuplicate: 'reject' while the same tool is already running) and no other tool call in the batch starts normally, any coordination that awaits firstToolStartedFuture will hang forever.

if (!toolOutput.firstToolStartedFuture.done) {
  toolOutput.firstToolStartedFuture.resolve();
}

const duplicateResult = await this.checkDuplicate(...);
if (duplicateResult !== undefined) return duplicateResult;

The firstToolStartedFuture must be resolved even when a tool call is duplicate-rejected by the executor. The resolution was previously unconditional (before the executor existed), but now it only fires inside onUserToolStarted which requires runTool to be called.

Approach: After the executor.execute() call resolves (line 1198 in generation.ts, inside tracableToolExecution), check if firstToolStartedFuture is still pending and resolve it. Alternatively, resolve it inside the executor's execute() method right before returning the duplicate result (at tool_executor.ts:220), by calling onUserToolStarted() before the early return. The latter approach is cleaner since it keeps the signaling logic co-located with the execution path.

Was this helpful? React with 👍 or 👎 to provide feedback.

🚩 ElevenLabs STT default commit strategy changed from 'vad' to 'manual'

At plugins/elevenlabs/src/stt.ts:653-654, the default commit strategy is now 'manual' when serverVad is undefined (the constructor default). Previously, the condition was this.#opts.serverVad === null ? 'manual' : 'vad', meaning undefined (unset) defaulted to 'vad'. Now both undefined and null map to 'manual'. This changes the default behavior for users who don't explicitly set serverVad — they'll get manual commit strategy instead of VAD-based. The test updates at lines 283 and 396-408 confirm this intentional change. Users relying on the old default VAD behavior without explicitly setting serverVad will need to pass serverVad: {} to restore it.

Was this helpful? React with 👍 or 👎 to provide feedback.